Categories
Node.js Best Practices

Node.js Best Practices — Production Environment

Spread the love

Like any kind of apps, JavaScript apps also have to be written well.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at some best practices we should follow when writing Node apps.

Get Frontend Assets Out of Node

Our node app shouldn’t server front end assets.

Instead, we can use dedicated middleware to do this.

Node performance isn’t good when dealing with many static files since it’s single-threaded.

Be Stateless

Our app should be stateless.

This means that we should store any state in our app in external data stores.

We can kill our servers periodically or use serverless platforms like AWS Lambda that enforces stateless behavior.

This way, we can kill our server without having any downtime.

Use Tools that Automatically Detect Vulnerabilities

Any package can have vulnerabilities that put our app at risk.

This can be tamed using community and commercial tools to check for them.

This way, we can patch them as fast as we can.

We don’t want to do this tedious task manually all the time.

Assign a Transaction ID to Each Log Statement

Assigning a transaction ID to each log statement makes them easy to find.

This is because Node apps have lots of async code, so it’s hard to know the order in which things are logged without a unique ID for each entry.

Without IDs, it’s pretty hard to tell what comes first and what comes later.

Set NODE_ENV=production

We can set NODE_ENV to production so that production optimizations get activated in production.

Many NPM packages optimize their code for production.

For example, if we forgot to set NODE_ENV to production in production, Express will be slower by a factor of 3.

Automated, Atomic and Zero-Downtime Deployments

Automated deployments are essential.

They let us deploy things without hassle or risk.

They also have to be atomic so that we can reverse deployments easily in case anything goes wrong.

Any manual steps carry big risks.

If we deploy manually, then we deploy less often, and that means even bigger risks.

Use an LTS release of Node.js

The LTS version of Node.js is supported for longer with bug fixes, security updates, and performance improvements.

Therefore, we should use them so that we can keep getting updates without upgrading to a new version all the time.

If we don’t keep our Node version up to date, then we risk ourselves with vulnerabilities.

Don’t Route Logs within an App

Log destinations shouldn’t be hardcoded by developers but it should be defined by the execution environment that they’re running in.

This way, our app can log to different places according to the environment it’s running in.

Install Packages with npm ci

With npm ci , the packages are installed with the versions from package-lock.json .

A clean install is done every time we run it.

This way, we won’t have to worry about package discrepancies.

Linter Security Rules

Linter security rules help us catch security with our Node apps quickly.

eslint-plugin-security is an ESLint plugin to help us catch those in a flash.

This way, we can fix security issues that are caught right away.

Conclusion

We should follow some guidelines when we go to production.

They’ll make our lives easier and reduce risks in various ways.

By John Au-Yeung

Web developer specializing in React, Vue, and front end development.

Leave a Reply

Your email address will not be published. Required fields are marked *